Draft

OGC Best Practice

OGC CityGML Implementation Guidance (Best Practice)
Tamrat Belayneh, Esri Editor Luis Gisler, Esri Editor
Version: 1.0
Additional Formats: XML PDF DOC
OGC Best Practice

Draft

Document number:24-999
Document type:OGC Best Practice
Document subtype:General
Document stage:Draft
Document language:English

License Agreement

Use of this document is subject to the license agreement at https://www.ogc.org/license




I.  Abstract

The CityGML Best Practices Document aims to address fragmentation and inconsistency in CityGML implementations by providing a standardized approach that consolidates frequently used aspects of CityGML. This document seeks to increase CityGML adoption, enhance interoperability, and offer a template for cities to publish consistent CityGML data while harmonizing various encodings and implementations.

It focuses on reducing fragmentation by selecting and promoting the most commonly used elements of CityGML, mitigating challenges posed by diverse modules, Levels of Detail (LODs), and geometric definitions. The document also addresses interoperability issues stemming from heterogeneous software support and aims to avoid redundancy by standardizing profiles, thus promoting consistency and efficiency.

Inspired by existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the CityGML Best Practices Document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will develop a minimal template covering key elements like buildings, street furniture, bridges, and vegetation. The document will be created in consultation with cities with established CityGML workflows to ensure it meets practical, real-world requirements.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, CityGML, CityJSON, 3D


III.  Preface

In March 2024, during the 128th OGC Member Meeting in Delft, Netherlands, discussions began among members and co-chairs of the 3DIM, Geo for Metaverse, Urban Digital Twins DWGs, and the CityGML SWG about the need for an OGC profile or best practice document to address fragmentation and inconsistency in CityGML implementations. This led to a formal proposal presented at the 129th OGC Member Meeting in Montreal, Canada, advocating for a standardized approach to consolidate frequently used aspects of CityGML.

The proposed CityGML Best Practices Document aims to enhance adoption, improve interoperability, and provide a consistent template for publishing CityGML data while harmonizing various encodings and implementations. It focuses on reducing fragmentation by standardizing the most commonly used elements of CityGML, addressing interoperability issues from diverse software support, and avoiding redundancy through standardized profiles.

Drawing on existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will provide a minimal template for key elements like buildings, street furniture, bridges, and vegetation, and will be developed in consultation with cities with established CityGML workflows to ensure it meets real-world needs.

IV.  Security Considerations

No security considerations have been made for this Standard.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

  • Esri
  • HFT
  • TU Delft
  • Virtual City Systems
  • Conterra

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

NameAffiliationOGC member
Tamrat BelaynehEsri, USAYes
Volker CoorsHFT, GermanyYes
Hugo Ledoux, Jantien StoterTU Delft, NetherlandsYes
Claus NagelVirtual City Systems , GermanyYes
Christian DahmenConterra , GermanyYes

VII.  Contributors

Additional contributors to this Standard include the following:

Rob Atkinson, OGC

1.  Scope

This document provides best practices for effectively using CityGML, with a focus on its application across a range of scenarios frequently encountered by cities and municipalities. It is designed to guide the use of CityGML as a robust data model for storing geometric information related to the built environment within a 3D System of Records.

Interoperability

  • This best practice document aims to enhance interoperability between various software packages, facilitating seamless integration and implementation of CityGML for developers. By standardizing practices, it supports consistent and efficient use across different platforms and applications.

  • The document is tailored to address the most common use cases for CityGML, particularly the storage and management of geometric data concerning the built environment in a comprehensive 3D warehouse.

The document adopts a semantically minimal approach, focusing exclusively on attributes directly related to built objects. This approach ensures clarity and avoids unnecessary complexity. It acknowledges that cities may use additional, specialized systems to manage other types of data, such as demographics, traffic flows, and similar information. As such, this best practice document does not encompass these areas but provides the flexibility for implementers to connect to external resources or extend the profile to suit specific needs.

2.  Conformance

This Best Practice defines XXXX.

Requirements for N standardization target types are considered:

  • AAAA

  • BBBB

Conformance with this Best Practice shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC® interface Best Practice, a software implementation shall choose to implement:

  • Any one of the conformance levels specified in Annex A (normative).

  • Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).

All requirements-classes and conformance-classes described in this document are owned by the documents(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Identification of Common Molecular Subsequences. Smith, T.F., Waterman, M.S., J. Mol. Biol. 147, 195–197 (1981)

ZIB Structure Prediction Pipeline: Composing a Complex Biological Workflow through Web Services. May, P., Ehrlich, H.C., Steinke, T. In: Nagel, W.E., Walter, W.V., Lehner, W. (eds.) Euro-Par 2006. LNCS, vol. 4128, pp. 1148–1158. Springer, Heidelberg (2006)

The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).

Grid Information Services for Distributed Resource Sharing. Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C. In: 10th IEEE International Symposium on High Performance Distributed Computing, pp. 181–184. IEEE Press, New York (2001)

The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration. Foster, I., Kesselman, C., Nick, J., Tuecke, S. Technical report, Global Grid Forum (2002)

National Center for Biotechnology Information, http://www.ncbi.nlm.nih.gov

ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.

ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.

ISO: ISO 19157:2013, Geographic information  — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.

ISO: ISO 19139:2007, Geographic information — Metadata — XML schema implementation. ISO (2007).

ISO: ISO 19115-3, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva https://www.iso.org/standard/80874.html.

Joan Masó and Lucy Bastin: OGC 15-097r1, OGC® Geospatial User Feedback Standard: Conceptual Model. Open Geospatial Consortium (2016). http://www.opengis.net/doc/IS/guf-conceptual/1.0.0.

Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). http://www.opengis.net/spec/citygml/2.0.

Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker: OGC 14-005r3, OGC® IndoorGML. Open Geospatial Consortium (2014). http://www.opengis.net/doc/IS/indoorgml/1.0.0.

Arliss Whiteside Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010).

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

term used for exemplary purposes

Note 1 to entry: An example note.

Example

Here’s an example of an example term.

[SOURCE: ISO 19101-1:2014]

5.  Conventions

This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1.  Identifiers

The normative provisions in this document are denoted by the URI

http://www.opengis.net/spec/{standard}/{m.n}

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

6.  Clauses not Containing Normative Material

Paragraph

6.1.  Clauses not containing normative material sub-clause 1

Paragraph

General Principles:

  • Flat representation (similar to 3DCityDB & CityJSON) → not really profile

  • Semanticall Thin (link to external sources, rather than copyying in)

  • Avoid Reduancy (if better sources are usually available, i.e. terrain, road)

7.  Real World Use Cases / Applications (informative)

This section describes common real world use cases (used in practice or planned for) for the use of this best practice profile by cities and planning authorities.

7.1.  Urban Planning & Design

7.1.1.  Urban Plan Communication

Communicating new developments and masterplans to the public.

Required Modules: Buildings

Benefititial Modules: Appearance

LOD: High

7.1.2.  Urban Planning / Comprehensive Planning

Overview of projects accross cities (permiting building status) SOR of planned projects

Manage KPIs such as GFA Mix, FAR etc.

To guide the long-term development of urban areas, balancing land use, infrastructure, and environmental sustainability. To assess and optimize the spatial arrangement of residential, commercial, industrial, and recreational areas, as well as transportation networks, utilities, and green spaces. In urban planning, the focus is on developing strategies to manage the growth and development of cities in a way that meets the needs of current and future populations while ensuring environmental sustainability. This involves comprehensive planning of land use, zoning, transportation, and the integration of various urban systems. The use of 3D models aids planners in visualizing the entire urban environment, understanding how different components interact, and simulating potential outcomes of different planning scenarios. This allows for informed decision-making and helps in balancing competing needs like housing, infrastructure, and green space.

Relevant thematic modules in CityGML for this use case include:

Building (for the visualization and analysis of existing and planned buildings, their heights, densities, and potential land use) LandUse (to manage and plan the zoning of different areas for residential, commercial, industrial, and recreational purposes) Transportation (to model transportation networks, including roads, railways, and public transport systems, supporting planning of efficient movement and connectivity) Relief (to incorporate topography and terrain data, which influences planning decisions related to construction, drainage, and infrastructure) Vegetation (to plan and integrate green spaces, parks, and tree coverage within urban areas, promoting sustainability and enhancing quality of life) CityFurniture (to plan the placement of urban elements such as benches, lighting, and public facilities that improve the livability of spaces)

7.2.  Simulation & Analysis

7.2.2.  Solar Potential & Solar Irradiance

The estimation of the solar potential for roofs and facades is an often cited application for 3D City Models and many cities …​.

7.2.3.  Daylight Simulations

In some countries, Daylight simulations are part of the urban planning or building permit process.

  • To assess the impact of a new construction on daylight in existing buildings in the neighborhood

  • To assess if requirements for daylight are met in a new buildings

The latter is usually conducted using architectural tools, using a detailed 3D model of the building in question (i.e. BIM) and less detailed models of the surrounding context. In this case, the 3D City Model only serves as a source for context and does not require detailed information on rooms or windows.

The first case typically includes the calculation of solar irradiation at window level of surrounding buildings. This requires information about the position and size of the the windows. Currently, most cities do not have this information available for existing (older) buildings.

Relevant Modules: Buildings Required Information: Windows

7.2.4.  Noise Simulation

Noise Simulations become increasingly important as part of the urban planning process. The simulation input is usually noise sources and obstacles from which the propagation of noise is calculated.

3D City models are a useful foundation for the calculation of noise propagation as they include physical obstacles (buildings, sound barriers, vegetation) and potentially also include information about the acoustic properties of horizontal and vertical surfaces (hard vs soft surfaces).

While possible (i.e. Dynamizers) Noise sources are usually not stored as part of the 3D City Model and are derived from other sources (i.e. road database, which includes speed limits, surface material and traffic count).

The calculation of the noise propagation is performed in a dedicated software. An ETL process, combining different sources and preparing a suitable input format for the software is required. For performance benefits, a lower LOD of the city model is usually preferred.

→ requires semantic information about hard vs soft surfaces → requires informatio about speed limit etc on street → external reference

Relevant Modules: Building, Vegetation, Transport, CityFurniture (Walls), Relief? Relevant Properties: Acoustic Surface Properties

7.2.5.  Flood Simulation

In some locations, flood simulations are an essential part of urban planning and emergency precaution.

The main input to the simulations are terrain and 3D objects (i.e. buildings). For more accurate calculations, information on ground roughness and infiltration capacity (permeable vs impermeable) are required.

While the simulation could theoretically be ran on a 3D City Model, the common hydorological models and simulation softwares rely on homogenous and continous raster DTMs as input.

These are in practice derived from a rasterized top view of the 3D objects (i.e. Buildings) combined with a DTM and (if applicable) additional raster layers describing surface coverage and permeability.

Required Modules: Building, CityFurniture, Relief Optional Modules: Vegetation

7.2.6.  Urban Climate Indicators

This use case is commonly applied in urban design and planning to understand the environmental effects of urban form, building materials, vegetation, and street layout. The simulation typically models how elements like building density, orientation, and green spaces influence the local microclimate, such as heat distribution, airflow, and sunlight exposure. By analyzing the interaction between buildings and the surrounding environment, urban planners can identify areas susceptible to overheating, poor air circulation, or uncomfortable wind conditions, enabling them to design more climate-resilient urban spaces.

  • To assess the impact of urban development on local microclimates, such as temperature variation, wind patterns, and air quality.

  • To evaluate how new construction or changes to urban infrastructure affect the comfort, livability, and sustainability of the urban environment.

Relevant thematic modules in CityGML for this use case include:

  • Building (for detailed 3D geometry and materials, which influence heat absorption and wind flow)

  • Vegetation (to model green spaces that impact air quality and temperature regulation)

  • Relief (to account for terrain and topography, which can affect wind patterns and heat distribution)

  • CityFurniture (to represent urban elements like trees, benches, and shelters that contribute to microclimate conditions)

*Transportation (to model roads and their effect on urban heat islands and airflow)

7.3.  Urban Heat Island Effect Assessment (combine with above?)

To assess the impact of urbanization on local climate conditions, particularly the urban heat island effect. To identify areas of the city that are more susceptible to extreme heat and recommend mitigation strategies. The urban heat island effect occurs when urban areas experience higher temperatures than their rural surroundings due to human activities and the built environment. 3D city models help simulate temperature variations across the city, taking into account factors like building materials, vegetation, and heat-emitting infrastructure. This can guide decisions related to urban design, green spaces, and energy-efficient building strategies.

Relevant modules in CityGML:

Building (for analyzing the effects of building materials and urban density on heat retention) Vegetation (for evaluating the cooling effect of parks, trees, and other green spaces) Relief (to assess how the city’s topography influences heat distribution) CityFurniture (for considering how small-scale urban elements like pavements and streetlights contribute to heat)

7.3.1.  First Response (Indoor )

  • To assist firefighters and emergency responders in navigating buildings during emergency situations, such as fires, ensuring efficient and safe operations.

  • To provide real-time, spatially accurate information about building layouts, exits, hazards, and key infrastructure to improve response times and reduce risks. In the first response use case, the goal is to equip emergency responders with detailed building information that can help them navigate quickly and effectively during high-pressure situations. Accurate and up-to-date 3D models of buildings can provide real-time data about building layouts, fire exits, hazardous materials, and emergency systems such as sprinklers, elevators, and ventilation. This allows firefighters to plan their routes more effectively, assess risks, and make informed decisions on the spot, improving both safety and efficiency in emergency operations.

Relevant thematic modules in CityGML for this use case include:

Building (to provide detailed 3D geometry of building structures, including rooms, corridors, staircases, and entry/exit points, which is essential for navigation during emergencies) BuildingPart (to represent individual floors, rooms, and sections of a building, enabling responders to locate specific areas and identify potential hazards such as storage rooms or chemical hazards) BuildingInstallation (to include critical infrastructure like fire alarms, sprinkler systems, ventilation shafts, and electrical panels that need to be accessed or disabled during a fire emergency) CityFurniture (to map exterior elements like hydrants, access points, and street furniture that aid in emergency response outside the building) Relief (to incorporate terrain and topography information that can influence accessibility to the building, especially in multi-story or uneven terrain environments)

7.3.2.  Facility Management of Buildings

  • To manage the lifecycle of buildings and infrastructure, ensuring efficient maintenance, operation, and optimization of resources.

  • To monitor and assess the condition of building components, systems, and equipment for timely interventions, repairs, or upgrades.

This Use Case is not in the scope of this Best Practice as it focuses on single buildings. While it is theoretically possible to use CityGML, it is recommended to rely on BIM (IFC) models for this use case. While CityGML is focused on urban scale and context, IFC is better suited for managing the detailed, technical data required during construction and lifecycle management of buildings.

7.3.3.  3D Cadastre

  • To manage, visualize, and assess ownership, land use, and legal rights over three-dimensional parcels of land.

  • To facilitate the registration of complex property boundaries, including underground and above-ground spaces, and resolve conflicts between overlapping land rights.

In the context of 3D cadastre, the goal is to extend traditional 2D land registries to include the full vertical and underground dimensions of urban space. This is especially relevant in dense urban environments, where buildings, utilities, and infrastructure often span multiple levels or go underground. The 3D cadastre use case supports the creation of legal and ownership boundaries for both above-ground and sub-surface spaces, such as air rights, underground utilities, and property extensions like balconies or rooftops. It also aids in resolving conflicts between adjacent properties and facilitating the legal management of complex land use scenarios.

Relevant thematic modules in CityGML for this use case include:

  • Building (to define the vertical extent and boundaries of buildings and their ownership, including roof and basement spaces)

  • BuildingPart (to represent individual building components, such as floors or rooms, which may have different owners or legal statuses)

  • LandUse (to define the land use and zoning regulations, supporting the management of property rights in accordance with urban planning)

Optional/TBD * Transportation (for defining rights of way and boundaries of roads or public transportation infrastructure that may intersect or overlap with private properties)

7.4.  Summary of required Information

Table 1

Use Case2nd Level Information (i.e. rooms)surface semantics (i.e. roof, windows)
Urban Plan Communicationnot requirednot required
Comprehensive Planningbenefitialnot required
Sight Analysisnot requirednot required
Shadow Analysisnot requirednot required
Solar Potential Estimationnot requiredbenefitial
Daylight Simulationoptionalrequired
Noise Simulationnot requiredoptional
Flood Simulationnot requiredoptional
Urban Climate Indicatorsnot requiredoptional
Indoor Wayfinding (First Response)requirednot required
Facility Managementrequirednot required
3D Cadastrerequirednot required

7.5.  Conclusion (Qualitative)

  • Buildings ist most used Module in the CityGML Data Model for 3DCIM applications

  • 2nd Level Building features (Rooms, Storey) are not yet widely used in practice, but cities are planning to use it and use cases have been described

  • Semantic Surface Information (especially “windows”) are required for certain Simulation applications and improve the results of others. However, currently most existing 3D city models do not contain semantic information on surfaces. Some models do differentiate between “Roofs” and “Walls”, but not “windows”. This is mostly due to the fact that aquiring this information requires either a semantically correct BIM model as a source (for newer buildling), or an established workflow to derive this information from other sources (i.e. photogrammetry, street images)

  • Some use cases require information that are usually stored in dedicated systems, (i.e. traffic, demographics), rather than maintaining a semantically thick data motdel, real world applications suggest the use of external references

  • Simulation which requires surface semantics often requires specific file format as input, hence a convertion is needed

→ show diagram, sources

Summary of Requirements as a Table

8.  Base Profile (normative)

8.1.  Modules

The CityGML Best Practice Guidance document provides an overview of how various CityGML modules align with the CityGML Standard.

CityGML encompasses several modules. The overall CityGML data model is thematically decomposed into a CityGML core module and extension modules. Each module is defined within its own globally unique XML namespace. Due to this modularization approach, there are various versions of valid CityGML documents are not valid CityGML 1.0.0 instance documents. As a result the Best Practice Guidance documents details varying levels of support:

The document also notes that database solutions are specific, and alternative methods are recommended for formats like RasterRelief that are not supported.

Table 2

CityGML moduleIncludedComment
CorePARTIALNURBS are not supported, Implicit Geometries are not supported .ExternalReferences are not supported.
AppearancePARTIALthe CityGML class TexCoordGen is not supported, ie one must specify the UV coordinates in the texture files.
BridgeYES
BuildingYES
CityFurnitureYES
CityObjectGroupPARTIALgroups of City Objects are supported, but not groups of parts of objects (eg it is not possible to group some walls of a building together)
ConstructionPartialSemantic surfaces are not supported
DynamizerNOSemantically thin, dedicated systems
GenericsYES
LandUseYES
PointCloudNO
ReliefNoonly the TINRelief/TriangulatedSurface is supported.
TinNO(where only elevation points and break lines are stored) is not supported since it would require viewer/applications to have a constrained Delaunay triangulator, which is problematic (especially for web-based tools). Also, it is not possible to store areas over a terrain that would support different resolutions.
RasterReliefNOis also not supported → other, better formats?
TransportationTBD
TunnelTBD
VegetationYES
VersioningNOCityJson using git based approach, Database specific solutions?
WaterBodyTBD

8.2.  Required Modules

8.2.1.  Building Module

Applications must partially support the buildings module to comply with this profile.

Recommended classes:

Building & Building Part Applications shall support the TopLevelFeatureType “Building” as well as the FeatureType “BuildingPart”.

Storeys & Rooms Applications may support the FeatureTypes “BuildingRoom”, “BuildingUnit” and “Storeys”

Not recommended classes:

Building Installation & Furniture Applications may support the FeatureTypes “BuildingInstallation”, “BuildingUnit” and “Storeys”

Constructive Elements Applications may support the FeatureTypes “BuildingContructiveElements”,

 

UML of class Building

Figure 1 — UML of Building Module

8.2.3.  Vegetation Module

 

 

UML of class Vegetion

Figure 3-1

===

==== CityFurniture Module

=== Optional Modules

==== Tunnel Module .UML of Tunnel Module image::./figures/UML_Tunnel.bmp[height=150]

==== Construction Module The support of the "Constructions""module is not required for compliance with this profile.

→ better to use alternatives/ifc → no use cases that warrent the query of individual surfaces / constructive elements accross city

==== Construction Module The support of the "CityObjectGroup""module is not required for compliance with this best practice.

 

UML of class Construction

Figure 3-2 — UML of Construction Module

==== Relief

  • Tin: Support is impractical due to constraints with Delaunay triangulation.

  • RasterRelief: TINRelief/TriangulatedSurface is supported; alternatives for unsupported formats are suggested.

→ in practice often from different source, also dedicated formats

==== Land Use

==== Water Body

==== Tunnel Module

==== Generics Module

==== Transportation Module

→ recommended to use dedicated systems?

==== Appearance The support of the "Constructions""module is not required for compliance with this profile.

→ alternatives way of storing textures?? also reality meshes

=== Excluded Modules Excluded from this profile. The following modules are not considered in the context of this best practice document.

==== Versioning The Versioning module is excluded from the scope of this profile. It is recommended to rely on a external version control (git) or database system to handle version control.

==== Point Cloud The Point Cloud module is excluded from the scope of this profile. It is recommended to use optimized storage formats and systems for point clouds.

==== Dynamizer The Versioning module is excluded from the scope of this profile. It is recommended to rely on dedicated systems / records for this kind of data.

=== Geometry Objects ==== Geometry Types The CityGML Conceptual Model does not put any restriction on the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS).

In order to improve interoperability and facilitate implementation, this profile restricts to the use of 3d polygons and 3d meshes.

==== Implicit Geometry

Geometry shall be explicitly defined and may not be implicit.

=== CRS

All CityObjects shall use the same CRS.

The coordinate reference system (CRS) shall be defined as a URL formatted according to the OGC Name Type Specification:

http://www.opengis.net/def/crs/{authority}/{version}/{code}

where {authority} designates the authority responsible for the definition of this CRS (usually "EPSG" or "OGC"), and where {version} designates the specific version of the CRS ("0" (zero) is used if there is no version).

A projected, cartesian coordinate system shall be used.

== Conformance Class Abstract Test Suite (Normative)

NOTE 1:    Ensure that there is a conformance class for each requirements class and a test for each requirement (identified by requirement name and number)

=== Conformance Class A

==== Requirement 1

Requirement 1

Test purpose

Verify that…​

Test method

Inspect…​

==== Requirement 2

== Title ( {Normative/Informative} )

NOTE 2:    Place other Annex material in sequential annexes beginning with "B" and leave final two annexes for the Revision History and Bibliography

== Revision History

DateReleaseEditorPrimary clauses modifiedDescription
2016-04-280.1G. Editorallinitial version

== Bibliography

NOTE 3:    The TC has approved Springer LNCS as the official document citation type.

Springer LNCS is widely used in technical and computer science journals and other publications

  • For citations in the text please use square brackets and consecutive numbers: [1], [2], [3]

– Actual References:

[n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published)

  • [], OGC: OGC Testbed 12 Annex B: Architecture (2015).